AI 可以幫你寫出程式，卻無法替你決定架構

今年 2026 年，是 AI 的快速發展，正在改變軟體工程師的工作模式。撰寫程式的門檻逐漸降低，但真正決定系統成敗的，依然是架構設計、問題分析與技術選型。程式寫錯了可以修，架構設計錯了，往往會造成效能瓶頸、資料不一致、服務互相依賴、系統無法擴展，甚至一次錯誤的設計決策，都可能造成嚴重的商業損失。

系統設計，其實是在學習怎麼做選擇

系統需要考量的事情很多。

資料要怎麼儲存？
交易範圍應該怎麼切？
什麼時候需要 Cache？
為什麼需要 Message Queue？
系統掛掉之後怎麼恢復？
重複請求怎麼處理？
資料不一致時又該相信誰？

當系統規模越來越大，我們會遇到更多問題，也會因此出現更多技術、工具與設計概念。

目前預計會從一些 System Design 的基本概念開始，再慢慢延伸到：

• Database 與資料儲存
• Transaction、Isolation Level 與 Lock
• Cache
• Message Queue
• Distributed System
• Consistency 與 CAP
• ID Generation
• Rate Limiting
• Idempotency
• Event-Driven Architecture
• 以及一些實際工作中遇到的系統設計問題

實際內容可能會隨著學習過程調整。

畢竟 System Design 的範圍真的太大了，一個問題往下挖，通常又會牽涉到另外三、四個問題。

所以這 30 天對我來說，比較像是建立一張地圖。

先知道有哪些重要的問題、有哪些常見的解決方法，以及這些東西彼此之間是怎麼連起來的。

它想解決什麼問題？為什麼需要它？用了之後，又會付出什麼代價？

因為系統設計很少存在唯一的標準答案。

更多時候，我們是在不同限制之間做選擇，理解每個方案背後的 Trade-off。

希望建立系統架構設計的基本功，學會思考「為什麼要這樣設計」，而不是只知道「怎麼使用技術」。
最後再補一些從業實際遇到的狀況，說明我的理解與解決方法。

文章我會留下幾個問題，可以腦筋思考一下，檢驗一下自己的理解是否正確
因為我覺得檢驗一個知識或是記憶點，最簡單的方式就是考試。
因為知識是需要可以被提取出來並應用的。

希望在這30 天內能建立基本的知識與架構，如果有不同的看法歡迎討論。

這次整理的內容會參考不少書籍、課程與技術資料，目前主要包含：

• Terry & Bohr 的《現代系統設計實戰營》
• Designing Data-Intensive Applications（DDIA）
• ByteByteGo / BigArchive System Design 2024
• 《內行人才知道的系統設計面試指南》上、下冊
• 其他技術文件、文章，以及自己的工作經驗

我不會在這裡討論到大型系統(Youtube, Google Drive)是怎麼設計的。
我可能會了解這些內容到滾瓜爛熟之後再來討論(也許是明年的鐵人賽)